host: repair a null saved record instead of failing every load - #2760

host: repair a null saved record instead of failing every load

Bot: Dev-5
Owner: Dev-5
Written-by: Dev-5
Fixes #2755

What was wrong

A state.json whose saved record for a room or a Bot is null — a truncated write, a hand edit, a restore from another machine, an older build — made load() throw a bare TypeError, and loaded ??= cached the rejection, so the team never appeared for the life of the process. Measured at f2ef4dfa: rooms: { r1: null } threw Cannot read properties of null (reading 'members') at adopt (store.js:379), and a version-1 bots: { chief: null } threw Cannot use 'in' operator to search for 'fields' in null at store.js:324; in both, readOnly() had no answer and no warning named state.json.

What changed

• Before a broken record is folded, the file as it was is copied to state.json.broken-<stamp> (the dropped value verbatim), and one warning names state.json.
• A broken room is kept and folded to members: []; a broken Bot record is dropped (no data is left to keep). The repair sets migrated, so the same load() writes the repaired version-2 file.
• A version-1 home with a broken record now migrates and writes version 2 while keeping state.json.v1; a read-only pass records the evidence copy but never writes state.json.
• If the evidence copy cannot be made, the file is left untouched and refused read-only with a readable reason, so a null answer is never the outcome.
• A healthy file still loads with no new warning and no .broken copy.

Red first

At base f2ef4dfaccedd40315bd585474d0902118dc0ba8, in core:

$ TZ=UTC node --import ./test/harness-resolve.mjs --test test/store.test.js
# tests 43 / # pass 40 / # fail 3   (exit 1)

The three failures are the new #2755 cases, with the original errors: Cannot read properties of null (reading 'members') at adopt (store.js:379:30) and Cannot use 'in' operator to search for 'fields' in null at adopt (store.js:324:20). The fourth new case is the healthy control and passes on the base.

At the tip the same command is # tests 43 / # pass 43 / # fail 0: null room folded and written back, .broken copy keeps r1: null, warning names state.json; version-1 null Bot migrated with .v1 kept and only that record dropped; read-only pass leaves state.json byte-identical; healthy team has no broken-record warning and no .broken file.

Ran at the tip

$ TZ=UTC ARCH_DOCS_BASE=f2ef4dfaccedd40315bd585474d0902118dc0ba8 npm run verify

exit 0: arch-docs: OK (6 changed file(s)); patches generate is a no-op; core 3140 pass, social 619 pass, tree 140 pass, timeline 161 pass, workflow 508 pass, .github/policy 671+37 pass, interop 34 pass; lint (oxlint, plugins, interop, live-e2e) clean.

Not run

The smoke bench (no core/src/host/ boot-path change beyond the store) and the CI package job's pack check / typecheck / actionlint.

Checkpoint

{
"pr": 2760,
"claim": "Dev-5",
"issue": 2755,
"summary": "A state.json record saved as null no longer hides the team: the file as it was is kept as a state.json.broken- copy, one warning names state.json, and the record is folded — a room kept with an empty member list, an unusable Bot record dropped. A version-1 home with a broken record migrates and writes version 2 while keeping .v1, a read-only pass records the evidence but never writes state.json, and a healthy file loads with no warning and no .broken copy.",
"files": [
"core/src/host/store.js",
"core/test/store.test.js",
"docs/subsystems/core-host.md",
"changelog.d/2755-state-null-record.fixed.md",
"patches/ds-bot/0002-flybot-api-host.patch",
"patches/ds-bot/0014-flybot-branding.patch"
],
"checks": {
"ran": "TZ=UTC ARCH_DOCS_BASE=f2ef4dfacced npm run verify",
"result": "green",
"at": "cbf57160f59c76035ddbb66eb18b802be2bc575f"
},
"next": "none — ready for review"
}